1. Field of the Invention
The field of the invention relates to data processing and in particular to diagnostic mechanisms for monitoring data processing operations.
2. Description of the Prior Art
There are a number of occasions where it is desirable to keep track of the processing being performed by a processing circuit. For example, such information is useful during the development of data processing systems. An example of a tool that may be used to assist in such a process is a tracing tool.
Tracing the activity of a data processing system whereby a trace stream is generated that includes data representing the step-by-step activity within the system is a highly useful tool in system development. Such tracing tools use a variety of means for tracing the program flow including embedded trace macrocells (ETM, a trademark of ARM Limited, Cambridge) which are present on the chip whose processing is being monitored.
These tracing tools can be used to reconstruct the state of a machine at a certain point during execution of the instruction stream and in order to do this may require knowledge of data transfers to registers if the contents of the registers are to be reconstructed or may require knowledge of data transfers to particular addresses if the memory state is to be reconstructed.
When tracing multiple load and store instructions it is important to understand which data transfers correspond to which CPU registers. The above is relatively straightforward if as is usual data transfers occurr in address order. In such a case the address can be used to identify the originating register. However, there are some problem cases such as the SWP instruction where both transfers are to the same address and in the case where filtering of trace data occurs (to reduce the amount of trace data output) so that only some of the data transfers of a multiple data transfer may be traced.
This has been addressed by ARM® of Cambridge England in its ETMv3 by defining the first transfer of the SWP instruction as always being the load and the second the store. With filtering it does not allow trace to be turned off during the tracing of a multiple data transfer, thus the number of data transfers traced is always the last set of a multiple data transfer. So in a LDM{r1-r5} for example, if there are 3 transfers traced, you know they are from r3, r4 and r5.
Although, some of the problems associated with relating individual data transfers from a multiple data transfer to the correct transfer have been addressed in the prior art, in the case of an out-of-order processor, the transfers may occur in any order and thus, simply not allowing trace to turn off during a multiple data transfer will not be sufficient to determine which of the multiple data transfer the transfers that are actually traced are as they could be any of them.
It should be noted that transfers occur out-of-order where for example some of the data values to be accessed are cached or where a register is not available for a store.
It would be desirable to be able to identify individual data transfers from a multiple data transfer even in an out-of-order processor.